Shouldn't that be

and probably we want to do something like

to associate the deallocator, but perhaps that means it has to be

#  define ALLOCATOR(dealloc) __attribute__((malloc, malloc(dealloc)))

define ALLOCATOR(dealloc) attribute((malloc, malloc(dealloc)))

I thought of that but clang does not support this form.

This form is somewhat useful for static analysis but it likely to lead to miscompiles as currently proposed to be integrated in LLVM. The problem is that the compiler doesn't track the hierarchy of allocators that are in use. An allocation path might have a call to alloc, whereas the deallocation path might end up being inlined to the point where it knows to call munmap or similar. I think that isn't a problem for the most recent snmalloc (we never hand actually unmap memory) but it might be a problem if we add the same attributes for the ranges (if you do a large thread-local allocation and free then we'll still hit the allocator path but may push it back into the thread's large chunk cache on deallocation and so enough might be inlined to confuse the optimiser into thinking that you've allocated with one allocator and freed with another).